7장. 배워야 할 기술들

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 7장 (pp. 137~149). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

AI가 개발자를 대신 코딩해주는 시대일수록, 전통적인 소프트웨어 엔지니어링 원칙은 사라지지 않고 오히려 더 중요해진다 — 이 장은 1부의 마지막 장으로서 그 원칙을 네 가지 핵심 기술로 압축하고, 2부에서 각각을 실습으로 풀어낼 지도를 남긴다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 나이퀴스트 안정성 기준을 근거로, AI가 만드는 속도 증가가 왜 더 빠르고 빈번한 피드백 루프를 요구하는지 설명한다.
• 이사벨라·빈센트 셰프의 대조를 근거로, 모듈화가 병렬 작업·이직률·장애 격리에 미치는 영향을 구분한다.
• 안데르스 에릭손의 의도적 연습 네 요소(전문가 코칭·빠른 피드백·의도적 연습·도전적 과제)를 AI 협업 학습에 적용한다.
• 진의 ffmpeg 실패담을 근거로, 형편없어 보이는 시도에서도 무엇을 배울 수 있는지 식별한다.
• 이 장의 결론이 2부(8장 이후의 주방 비유)로 이어지는 이유를 설명한다.

전체 흐름도

                    §1  배워야 할 네 가지 핵심 기술 (도입)
        빠른 피드백 · 모듈화 · 지속적 학습 · 전문 분야 숙달 — AI 시대에도 사라지지 않는 것들
                                  │
                                  ▼
                    §2  빠르고 빈번한 피드백 루프 만들기
      이사벨라 vs 빈센트 셰프(피드백 대조) · 나이퀴스트 안정성 기준 · 데브옵스 현황 보고서(CI/CD)
                                  │
                                  ▼
                    §3  모듈화 — 병렬 작업과 옵셔널리티의 토대
      댄 스터티번트 연구(비모듈 시스템·이직 9배) · ChatGPT 코덱스 팀의 커밋 속도 사례
                                  │
                                  ▼
                    §4  학습과 재학습 받아들이기
      의도적 연습(안데르스 에릭손) · 진의 ffmpeg·o1 실패담 · 학습의 네 요소
                                  │
                                  ▼
                    §5  자신만의 전문 분야 마스터하기
      이사벨라(요리를 사랑해서 한다) vs 빈센트(살기 위해 요리한다) — 사랑이 기술 탐색을 이끈다
                                  │
                                  ▼
                    §6  결론 — 소프트웨어를 만드는 방식의 재편
      에릭 메이어르의 선언 재조명 · 1부 다섯 가치 요약 · 저자 두 사람의 사례 · 2부로 넘어가는 다리

0. 용어 사전

참고 — 위쪽 3개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 1장·3장을 먼저 보라.

1. 배워야 할 네 가지 핵심 기술

모든 개발자가 매일 AI를 쓰는 시대가 도래했다. 도구는 빠르게 진화하고 있지만, 그렇다고 전통적인 소프트웨어 엔지니어링 원칙의 중요성이 줄어드는 것은 아니다 — 저자들은 오히려 최소한 지금만큼, 혹은 그보다 더 큰 역할을 하게 될 것이라고 본다. 그래서 이 장은 다음 네 가지를 반드시 배워야 할 기술로 제시한다.

빠르고 빈번한 피드백 루프를 구축해 검증과 제어를 원활하게 하는 것, 복잡성을 줄이고 병렬 작업과 다양한 선택지 탐색을 가능하게 하는 모듈화, 모든 것이 빠르게 변하는 세계에서 지속적으로 학습하는 능력, 그리고 지식 노동이 짧은 시간 안에 바뀌더라도 살아남아 성공을 이끌어줄 전문 기술의 숙달이다. 이 네 가지는 개발자나 바이브 코더만이 아니라, 지식 노동에 종사하는 모든 사람에게 중요해질 기술이라고 저자들은 강조한다.

2. 빠르고 빈번한 피드백 루프 만들기

시스템이 더 빠르게 움직일수록, 실패했을 때 위험이 더 클수록, 더 빠르고 더 빈번한 피드백이 필요하다. 반대로 시스템이 느리게 움직이고 실수가 큰 사고로 번지지 않는다면, 느리고 드문 피드백 루프로도 버틸 수 있다 — 빌드가 평소보다 몇 분 더 걸린다고 아무도 크게 신경 쓰지 않는 것과 같다. 그러나 시스템의 속도가 올라가면, 예컨대 코드 생성 속도가 10배 이상 빨라지면, 피드백 사이클도 그에 못지않게, 혹은 그보다 더 빠르게 빨라져야 한다. 피드백 루프가 통제력을 유지하고 시스템을 조직의 목표로 이끄는 안정화의 원동력이기 때문이다.

참고 — 나이퀴스트 안정성 기준. 제어 이론의 이 기준에 따르면, 어떤 시스템이든 통제 상태를 유지하려면 피드백이 시스템 자체보다 최소 2배 이상 빠르게 작동해야 한다. AI 보조 개발에서는 생성 속도가 증가하는 만큼 더 빠른 피드백 루프가 필요하다 — 레이싱카 운전자가 더 높은 속도에서 더 빠른 반사 신경을 필요로 하는 것과 같은 이치다.

상황. 실력이 동등한 두 셰프, 이사벨라와 빈센트가 각자 레스토랑을 운영한다.

잘못된 접근(빈센트 셰프). 빈센트 셰프는 피드백이 없는 진공 상태에서 주방을 운영한다. 테이블에 올라가기 전까지 누구도 요리를 맛보지 않고, 요리사들은 각자 고립된 채 일하며, 서버들은 주방에 손님의 반응을 전달하지 않는다. 품질이 의심스러운 해산물이 들어와도 그 사실이 아무에게도 전달되지 않는다.

올바른 접근(이사벨라 셰프). 이사벨라 셰프는 피드백에 철저히 집착한다. 수시로 온도계를 확인하고, 모든 단계에서 여러 요리사가 맛을 검증하며, 서버는 고객 반응을 즉각 주방에 전달하고, 스페셜 메뉴는 정식 메뉴에 오르기 전 시험 운영을 거친다. 파에야에서 약간 불쾌한 냄새가 나도 서빙 전에 알아차린다.

왜. 빈센트 셰프의 레스토랑이 실패하는 이유는 기술이 아니라 프로세스다 — 빠른 피드백을 구축하지 못했고, 심지어 문제가 생긴 뒤 대응조차 못 했다. 반면 이사벨라 셰프의 레스토랑은 시즌 내내 새 메뉴를 내놓으면서도 명성을 유지한다. 저자들 스스로도 AI가 통제를 벗어나 폭주했던 일화에서 이 교훈을 얻었다 — 몸에 밴 오랜 습관만으로는 부족했고, 점진적인 구축·잦은 테스트·끊임없는 검증만이 시스템을 안전하고 통제된 상태로 유지할 수 있었다.

점진적 구축·잦은 테스트·끊임없는 검증은 AI 파트너가 만드는 결과물의 신뢰성을 높이고, 영혼을 갉아먹는 동시에 가장 비용이 큰 작업인 재작업을 최소화한다. 다만 모든 것을 반드시 엄격하게 선형적으로 개선할 필요는 없다 — 먹이를 향한 최적 경로를 찾는 개미 떼처럼 여러 경로를 병렬로 탐색해도 되지만, 어떤 경로를 택하든 경로 중간중간 잦은 점검을 시행해야 한다.

데브옵스 현황 보고서. 저자 진과 동료 제즈 험블, 니콜 포스그렌 박사는 6년에 걸쳐 3만 6000명의 응답자를 대상으로 교차 집단 연구를 진행했다. 그 결과를 담은 《데브옵스 현황 보고서》는 CI/CD 파이프라인 구축을 통한 빠른 피드백 루프가 조직 성과를 예측하는 가장 중요한 지표 중 하나라고 밝혔다.

3. 모듈화 — 병렬 작업과 옵셔널리티의 토대

빠른 피드백이 안전하게 움직이기 위한 제어 메커니즘이라면, 모듈성은 시스템 분할을 지원한다. 시스템이 분할되어야 독립적인 행동을 수행하는 병렬 작업이 가능해진다. 독립성은 시스템을 더 탄력적으로 만들고, 낮은 비용과 위험으로 대안적 해결책(선택지)을 탐색하는 기능을 준다. 압력과 강도가 높은 상황에서 모듈성을 확보하는 것은, 혼돈을 벗어나 통제 가능한 전문 주방을 만드는 토대로 작용한다.

댄 스터티번트 연구. 댄 스터티번트 박사와 동료들은 얽혀 있고 비모듈적인 시스템에서 일하는 개발자들이 그만두거나 해고될 가능성이 9배 더 높다는 것을 밝혔다. 데브옵스 현황 보고서 역시 모듈형 아키텍처가 조직 성과를 예측하는 최상위 지표 중 하나라는 점을 보여준다.

ChatGPT 코덱스 팀 사례. ChatGPT 코덱스 팀의 알렉산더 엠비리코스는 한 엔지니어가 뛰어난 '커밋 속도'로 AI 도구를 써서 밑바닥부터 새 시스템을 구축한 성공 사례를 공유했다. 그런데 그 시스템을 초고속으로 성장한 모놀리식 시스템인 ChatGPT 코드베이스 안으로 이식했을 때, 즉 설계 문제가 있는 시스템으로 옮겼을 때 결과가 극적으로 달라졌다 — 같은 엔지니어, 같은 도구였음에도 커밋 속도가 곤두박질쳤다. 이 사례는 OpenAI에서도 아키텍처 제약이 AI를 쓰는 개발자에게 그대로 영향을 미친다는 사실을 보여준다.

이사벨라 셰프의 주방은 모듈화의 모범 사례다. 페이스트리, 그릴, 소스를 담당하는 각 스테이션은 공간·도구·책임이 명확히 구분돼 있어, 담당 셰프들은 시스템 전체를 붕괴시키지 않으면서 각자 영역에서 독립적으로 작업하고 실험한다. 스테이션 간 커뮤니케이션은 명확하고 표준화되어 있다. 반면 빈센트 셰프의 주방은 얽히고설킨 전쟁터와 같다 — 공용 도구는 제자리에 없고, 요리사들은 서로 부딪치고, 단순한 작업 하나조차 의존성 때문에 미로를 헤쳐나가는 기분이다. 병렬 작업은 고사하고 셰프들은 다른 사람의 작업에 막혀 기다리기 일쑤다.

코드와 프로젝트가 모듈화되지 않으면 코딩 에이전트와 사람들이 병렬로 작업할 수 없다. 서로 다른 작업(모듈 리팩터링·기능 구현·테스트 작성)을 수행하더라도 끔찍한 머지 충돌이나 관련 없는 기능이 망가지는 사태를 예방해야 한다. 모듈성 확보는 탄력성으로 이어진다 — 디스크 장애가 시스템 전체 장애로 번지지 않는 클라우드 서비스처럼, 모듈형 시스템은 실패를 가둬 전파를 막아야 한다. 하나의 모듈에 문제가 생겨도 폭발 반경은 제한되고, 시스템 전체를 중단시키지 않고도 해당 부분을 격리하거나 교체할 수 있다.

모듈성은 FAAFO의 핵심 요소인 옵셔널리티도 지원한다. 세 가지 다른 캐싱 전략을 리서치할 때 세 전략 모두를 독립적인 대안 모듈로 구축해 둘 수 있고, 새 UI 컴포넌트를 실험할 때도 여러 버전을 병렬로 개발할 수 있다. 요약하면 모듈성은 FAAFO의 모든 차원에서 더 많은 성취를 이끌어낸다.

4. 학습과 재학습 받아들이기

빠른 피드백 루프와 모듈성 못지않게 중요한 세 번째 기술은 '학습에 다시 익숙해지기'다. AI가 하루가 다르게 변하는 만큼, 최소한 당분간은 올바른 판단력을 기르기 위해 지속적인 학습과 연습에 시간을 써야 한다. 학습은 저절로 일어나지 않는다 — 위험을 감수하고 실수로부터 배우며 적응하는 과정을 통해서만 이루어진다.

이사벨라 셰프는 기이한 행동을 하는 수셰프라도 일단 받아들이고 끊임없이 배우는 학습자의 길을 선택한다. 실험을 하고, 요리 경진 대회를 열고, 자신만의 여정을 걷는 다른 헤드 셰프들을 찾아 나서며, 점점 까다로워지는 고객의 취향을 충족시킬 더 야심 찬 식사 구성을 만들어내는 법을 익힌다. 반면 빈센트 셰프는 새 수셰프 몇몇이 실수(생선을 너무 익히거나 수플레를 오므라들게 하거나 요리를 태우는)를 저지르자, 그 실수를 찍어 소셜 미디어에 올리고 조롱한다. 잠깐의 유명세는 얻지만, 시간이 지나며 급격히 변화하는 요리와 외식의 세계에서 뒤처진 자신을 발견한다.

학습도 학습할 수 있다는 사실은 뜻밖일 수 있다. 나이나 현재 상황과 무관하게 누구나 언제든 학습 능력을 향상시킬 수 있고, 학습은 코칭과 교육이 가능하다 — 집중과 생활 방식의 변화를 통해 뇌를 더 신경가소적이고 적응 가능하게 단련할 수 있다. 저자 두 사람도 지난 1~2년간 커리어의 그 어느 시기보다 더 많은 것을 배웠다고 말한다.

진의 ffmpeg 실패담. 진은 스티브와 함께 바이브 코딩을 처음 시작했을 때, 당시 새로 등장한 OpenAI의 o1 모델이 ffmpeg에 매우 능숙할 것이라 확신하고 비디오 발췌본에 자막을 삽입하는 작업을 맡겼다. 그러나 두 시간을 투자했는데도 점점 더 복잡해지는 ffmpeg 명령어를 입력하며 제자리를 맴돌았을 뿐이었다. 이때 AI는 실수 수준이 아니라 확신에 찬 어조로 틀린 대답을 내놓았다. 형편없는 경험이었지만, 진은 이 시도를 통해 특정 유형의 문제를 풀 때 언제 AI 사용을 포기해야 하는지에 대한 중요한 교훈을 얻었다 — 시도해야만 얻는 것이 있다는 것이다.

학습 마인드셋을 기르는 것은 타고난 천재성과 무관하다. 심리학자 안데르스 에릭손 박사가 설명한 대로, 학습은 의도적이고 계획적인 연습에 관한 것이다. 의도적 연습을 위해선 다음 네 가지가 필요하다.

• 전문가 코칭. 멘토·동료·AI 자체를 전문가로 활용해, 개념을 설명해 달라거나 접근 방식을 비평해 달라고 요청한다.
• 빠른 피드백. 촘촘한 검증 루프를 구축해, AI의 작업 결과와 프롬프트가 만들어내는 결과를 즉시 확인한다.
• 의도적인 연습. 프롬프트를 다듬고 익숙하지 않은 영역에서 AI의 제안을 평가하며, 다양한 기술을 의식적으로 연습한다.
• 도전적인 과제. 혼자서는 해결할 수 없다고 생각했던 문제에 AI를 적용해, 안전지대를 조금씩 넘어서는 도전을 한다.

5. 자신만의 전문 분야 마스터하기

주방을 AI 수셰프로 채우기로 마음먹었다면, 이제 개발자는 일반적인 소프트웨어 개발자가 아니라 책임자로서 역할을 다해야 한다. 그러나 저자들은 아직 가장 중요한 문제를 다루지 않았다고 말한다 — 요리하는 것을 좋아하지 않으면 이 모든 것이 아무 의미가 없다는 사실이다.

이사벨라 셰프는 요리를 사랑하기 때문에 발전한다. 모든 기법이나 최신 도구에 정통하지는 않을지라도 비전이 있고, 그 순간에 무엇이 중요한지 알며, 자신보다 특정 영역을 더 잘 아는 수셰프를 관리하는 능력을 갖추고 있다. 이사벨라 셰프는 요리를 하기 위해 산다. 반면 빈센트 셰프는 살기 위해 요리를 한다 — 오래전에 새 기법을 배우는 일을 그만두었고, 음식 맛이 그럭저럭 괜찮기만 하면 만족한다. 그 결과 음식이 훌륭하지 않아 그의 레스토랑을 찾는 사람은 거의 없다.

자신이 사랑하는 것을 만들고, 적어도 스스로 분명한 비전과 목표를 설정하면 기술 탐색과 습득은 자연스레 일어난다 — AI가 곁에서 도와주는 지금 상황에서는 더욱 그렇다. 필요한 것은 오직 의지뿐이라고 저자들은 말한다.

6. 결론 — 소프트웨어를 만드는 방식의 재편

저자들은 에릭 메이어르 박사의 인상적인 선언, '손으로 코드를 작성하는 시대는 끝나가고 있다'는 말에서 이 여정을 시작했다. 도발적인 발언이지만, 소프트웨어 생태계에서 일어나고 있는 근본적인 변화를 가장 단순하게 설명한 말이기도 하다. ChatGPT와 다른 AI 어시스턴트 때문에 싹튼 이 변화는 처음엔 장난감처럼 보였지만, 불과 2년 만에 전문가들도 쓰는 바이브 코딩으로 진화하며 소프트웨어를 만드는 방식 자체를 재편하고 있다.

1부에서는 바이브 코딩이 만들어내는 다섯 가지 가치의 차원(더 빠르게 코드를 작성하는 것, 더 야심 찬 계획을 세우는 것, 과거엔 팀이 필요했던 일을 자율적으로 혹은 혼자서 해내는 것, 더 많은 재미를 느끼는 것, 결정을 내리기 전에 여러 선택지를 탐색하는 것)을 살펴보았다. 이 다섯 가지 이점이 결합되면 개발자의 수준과 무관하게 비약적으로 도약할 가능성이 높아지고, 과거라면 영원히 미뤘을 프로젝트가 손이 닿는 범위 안으로 들어온다.

저자 두 사람에게도 바이브 코딩은 매우 개인적인 방식으로 삶을 바꾸었다 — 스티브는 30년 넘도록 수정되지 않은 버그와 미완의 열망 속에 정체되어 있던 게임 개발(와이번)을 재개했고, 진은 1998년 이후 닫혀 있다고 여겨왔던 코딩의 문을 다시 열어 2024년에 자신의 커리어를 통틀어 가장 많은 코드를 작성했다.

1부를 통해 바이브 코딩이 왜 중요한지 알아보았다. 이제 저자들은 주방으로 들어가 요리를 시작할 준비를 마쳤다고 말한다. 2부에서는 독자에게 칼을 쥐여주고 불을 켜, 첫 바이브 코딩 세션을 진행할 수 있도록 안내하며 바이브 코딩을 제대로 수행하기 위한 이론과 기초를 단계적으로 알아본다.

핵심 개념 정리

실무 체크리스트

• [ ] 우리 시스템의 속도가 빨라졌는데도, 피드백 주기는 예전 그대로 느리고 드물게 남아 있지는 않은가?
• [ ] AI가 만든 코드를 병합하기 전에, 온도계를 확인하듯 매 단계에서 검증하고 있는가?
• [ ] 여러 경로를 병렬로 탐색할 때조차, 경로 중간중간 점검 지점을 두고 있는가?
• [ ] 우리 코드베이스는 한 곳을 건드리면 다른 곳에서 예상 못 한 문제가 터지는 구조는 아닌가?
• [ ] AI 에이전트에게 작업을 맡기기 전에, 그 작업이 명확한 인터페이스를 가진 독립 모듈로 나뉘어 있는가?
• [ ] 실패했던 시도에서 "언제 AI 사용을 포기해야 하는가"에 대한 교훈을 실제로 기록해 두었는가?
• [ ] 전문가 코칭·빠른 피드백·의도적인 연습·도전적 과제 네 가지 중, 지금 팀에 빠진 것은 무엇인가?
• [ ] 최신 도구를 쫓는 것과, 내가 진짜 사랑하는 문제를 만드는 것 중 어느 쪽에 시간을 더 쓰고 있는가?

연습문제

1. 유형: 판단. 우리 팀은 AI가 생성한 PR을 하루 한 번, 배포 직전에만 검토한다. 최근 배포 주기는 하루 10회로 빨라졌다. 이 장의 나이퀴스트 안정성 기준을 근거로 이 검토 주기의 문제를 판단하라.
2. 유형: 분석. 한 신입 팀원이 AI로 3000줄짜리 함수를 순식간에 만들어냈고, 아무도 그 함수가 쓰는 인자 세 개를 제대로 이해하지 못한다. 이 장의 모듈화 논의를 근거로 무엇이 빠졌는지 분석하라.
3. 유형: 비교. 댄 스터티번트의 연구(이직 가능성 9배)와 ChatGPT 코덱스 팀의 사례(같은 엔지니어·같은 도구인데도 커밋 속도 급락)를 비교하고, 두 사례가 공통으로 가리키는 원인을 설명하라.
4. 유형: 실무 시나리오. 팀장이 "AI 덕분에 이제 새로운 언어를 배울 필요가 없다"며 팀의 학습 시간을 없애자고 한다. 이 장의 의도적 연습 논의를 근거로 이 결정에 반박하라.
5. 유형: 판단. 한 개발자가 두 시간 동안 AI에게 점점 복잡한 명령어를 요구했지만 끝내 실패했다. 이 장의 진의 ffmpeg 사례를 근거로, 이 상황에서 무엇을 판단하고 다음 시도에 어떻게 적용해야 하는지 서술하라.

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식·연구 원문, 생존 확인 2026-09-14)

• DORA 공식 출판물 페이지 — DORA Publications (이 장이 인용한 《데브옵스 현황 보고서》 계열의 공식 배포처)
• 안데르스 에릭손, 의도적 연습 개관 논문(PubMed 서지) — Deliberate practice and acquisition of expert performance: a general overview
• 댄 스터티번트 박사학위논문(MIT 공식 저장소) — System design and the cost of architectural complexity (이 장이 인용한 비모듈 시스템·이직률 연구의 원 논문)
• OpenAI Codex 공식 소개 페이지 — Codex | AI Coding Partner from OpenAI (이 장이 든 ChatGPT 코덱스 팀 커밋 속도 사례의 배경이 되는 도구)

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) 문제가 있다. 나이퀴스트 안정성 기준(§2)은 통제를 유지하려면 피드백이 시스템 자체보다 최소 2배 빠르게 작동해야 한다고 말한다. 배포 주기가 하루 10회로 빨라졌는데 검토 주기가 하루 1회에 머문다면, 피드백이 시스템 속도를 따라가지 못해 통제를 잃을 위험이 커진다. 검토 빈도를 배포 빈도에 맞춰 촘촘히 끌어올려야 한다.
2. (문제 2 정답) 모듈 경계가 없는 것이 문제다. §3은 모듈화되지 않은 코드에서 코딩 에이전트와 사람이 병렬로 작업할 수 없고, 독립적인 행동이 불가능해진다고 말한다. 3000줄짜리 함수를 아무도 이해하지 못한다는 것은 이 장이 경고하는, 압력 속에서 통제 가능한 구조를 만들지 못한 전형적인 사례다. 함수를 명확한 인터페이스를 가진 더 작은 모듈로 나눠야 한다.
3. (문제 3 정답) 두 사례 모두 시스템(조직) 구조가 개발자 개인의 역량보다 결과를 더 크게 좌우한다는 점을 가리킨다(§3). 스터티번트의 연구는 비모듈적 시스템에서 일하는 것 자체가 이직·해고 가능성을 9배 높인다는 통계로, ChatGPT 코덱스 팀 사례는 '같은 엔지니어·같은 도구'라는 통제된 비교로 같은 결론에 도달한다 — 문제는 사람이 아니라 아키텍처다.
4. (문제 4 정답) §4는 학습이 저절로 일어나지 않으며, 위험을 감수하고 실수로부터 배우는 의도적 연습을 통해서만 이뤄진다고 말한다. "AI가 있으니 배울 필요가 없다"는 판단은 정확히 이 장이 경계하는 태도다 — 진의 ffmpeg 실패담처럼, 새 도구·새 언어를 직접 시도해봐야만 '언제 AI 사용을 포기해야 하는지' 같은 판단력이 길러진다. 학습 시간을 없애면 그 판단력 자체가 자라지 않는다.
5. (문제 5 정답) §4의 진의 사례는 실패한 시도라도 그 자체로 가치가 있다고 말한다 — 두 시간의 실패를 통해 진은 "이런 유형의 문제에는 AI가 아직 적합하지 않다"는 것을 배웠다. 지금 상황에서도 실패를 재작업 낭비로만 볼 것이 아니라, 어떤 신호(점점 복잡해지는 명령어, 확신에 찬 오답)가 '포기 시점'을 알려주는지 기록해두고, 다음번 비슷한 작업에서는 그 신호가 보이는 즉시 접근 방식을 바꾸는 데 적용해야 한다.